In one of my latest stories within the ‘User Experience is …’ series, I started to explore how User experience is … for startups and enterprises.
Right at the outset you might have noticed that I'm using the term tool, instead of app, service or experience and that's mostly because within the workplace, the workforce will normally only use something if it helps them get their work done. They are not using things for pleasure or because they want to or like to, it's normally because they have to, to get a job done.
Within the previous exploration of designing experiences for enterprise and startups, people often asked why so many business to business, enterprise or internal products have terrible usability; let alone any sort of experience designed for them. After all these tools still have users who have a task to do, need to complete a goal and need to do something.
A big difference here is the dynamic of enterprise solutions, the difference being that the end user, might not not have a free choice around which tools they use, to get the job done. Whereas customers normally vote with their feet and if something isn't easy to do, then they might use a different tool or solution, even if it's not the cheapest.
Enterprise tools might not be purchased by the end user, they might not even be invovled in the decision making progress. Traditionally IT teams have been seen to make these decisions as most of the requirements for using a new tool or solution will come into IT's consideration and be deemed to be more central to the descision making progress. So things like stability, performance, data storage, security, integration points, API's, upgrade paths, support, license model and running costs. There is a nucleus of requirements here, which is why this often sits with IT. As decisions have often been based in isolated IT departments, solution providers are scored on this criteria, so they have prioritised these requirements, instead of the other organisation's requirements like the end user experience.
The challenge here is the colleague's view of a tool, how easy it is to use and does it achieve the goal that is needed from the organisation and end users. This can make the colleagues considerations and requirements more distant than the central requirements from IT. However it doesn't have to and a lot of the work done in the modern workplaces is to gather all of these requirements in order to make sure that tools and solutions are suitable for the workforce to use, no matter what devices they are using, where they are using the tool and if they might have additional access needs.
Along with involving users at the start of the procurement process, often end users haven't been involved in the sign off process of a new tool. So very little end user or colleague acceptance testing is done on common workflows and tasks with those who will be using the solution everyday, instead favouring technical testing over user testing, to make sure that features work technically.
This is where the business outcome and also user outcomes and benefits set out at the start of the discovery and exploration of the problem can be used to test with. Metrics and KPI's defined at the start from the outcomes can be used to test with, as well as task success measures to make sure that the solution improves the workflow and the experience is a postive one. The combination of both of these things can not only provide qualatative feedback from colleagues who will actively use the solution around their thoughts and feelings using their subject expertise and experience in the role, but also the qualatative measures can also provide feedback around easy of use, usability and experience. Using things like number of steps, time to complete and time to make decisions to compare the proposed solution to what's being used today.
Enterprise UX in a nutshell
"We need to find a way to hide complexity of all kinds, interface, software, organisational, departmental and process, behind sensible options that help colleagues navigate the space in a more predictable way. That’s the task of Enterprise UX."
User experience is … for startups and enterprises
Even though these tools might not be actually being used by the organisation's end customer, these tools will still have an impact on the customer experience. These will influence how decisions are made by colleagues, how the organisation operates and how flexible the organisation can be in the end experience for each customer, as well as their ability to recover from a less than perfect customer experience, if needed.
There will always be a workflow and a cost to the business to get a job, adding to the cost to do business. This cost could be poor decision making, due to either not having the information or the information being correct and accurate to base a decision on. It could be sheer time it takes to work through different tools, sign ins, workflows etc. in order to achieve the goal. Or it could be how effectively colleagues can manage intangibles, grey areas, risks etc. All of this affects the bottom line, the price of products and also the experience that an organisation's customer has.
Gathering meaningful and actionable feedback from end users can be challenging. This could be down to people's behaviour, as when people use a product frequently, they figure out workarounds quickly and get desensitised to usability issues. When asked for feedback they are far more likely to remember either the latest release or feature request rather than problems with the tools or how it affects their workflow.
Also when in the world of work people can be very unconfident about themselves and their ability and are very quick to blame themselves for issues instead of how the tools is supporting them.
When people first start using a solution feedback can often be skewed. They will obviously be using their own past experience to compare and contrast and as I've mentioned they may not be used to usable solutions, with well designed experiences. So they might just not know, what they don't know and have a blind spot on usability feedback. If they are able to do what they need in a good workflow then they might be forgiving of a great deal. They will often be comparing to how they do it today, which could be within an legacy old tool or even on paper and so the usability bar might be set quite low.
It's also worth bearing in mind that as a solution matures within a team that the quantity of the feedback becomes less, as they become accepting of it as the new normal and also the bias within the feedback becomes greater. There is also something in play where if you've not acted on previous feedback that colleagues will also question the value of providing feedback in the future as they will just become accepting of the solution, warts and all.
Cynefin framework, Edwin Stoop
Sometimes there's just no getting around it, colleagues will need to complete a complex task, using information and data from different sources, in order to build context and insight, so that a considered decision can be made for now, next and later. This might include needing to use multiple information sources, building a context in order to make a decision or making multiple decisions. Within these situations support and guidance often works to make things more usable without inheriantly making them more simple. Guidance mixed with making sure that the information is not hidden and formatted and presented in the expected way that is the most usable and understandable, while supporting colleagues within these complex tools.
Cynefin framework, Edwin Stoop
One of the key dark patterns in enterpise tools is the whole industry that has been added to onboard and train colleagues into products that are complex or poorly designed. Training can't replace a good workflow, designed experience or usabile tool, even if they are complex. Often UX works to reduce or remove complexity and make things simpler to understand and complete. However sometimes within Enterprise tools things are just complex.
Contextual support, understanding the workflow and decisions that needed to be made always works better than onboarding and training. Training is often done at a moment in time and then forgotten. Also written training is not absorbed and retained as much or as long as on the job training, or being guided through something and doing it for yourself. Often when tracking is added to any training, you'll find that it is rarely used, even if it's mandated and drop offs are common during the training meaning that all of it isn't done. People will dismiss training in favour of actually getting the task done and training can often be thought about as getting in the way of getting something done.
When designing solutions in Enterprise, you'll often work with Subject Matter Experts, who often take on the pseudo role of the end user or colleague. As Subject Matter Experts work within the organisation they feel a certain intimacy with the solution and how things should be done. However foten the persective of the support centre and how things should or could be done, doesn't play out in the reality of the end users and colleagues in the environment where the solution is being used. This is where certain biases set in with teams working in products who are either knoweldgeable or powerful. The HIPPO (HIghest Paid Person's Opinion) also sometimes plays a part in this, which causes a microcosm where a solution is designed based on bias, assumptions and thoughts on what could or should be done for the benefit of central support teams workflows, but not based on the colleagues workflow in reality and for the benefit of completing the task in hand.
These stakeholders can also hold the assumption that 'powerful' solutions are often fussy and tempermental. They will find it hard to imagine how a 'powerful' solution can also be usable. They will often focus on the possibilities and how 'powerful' the tool can be, which forces things to be designed more generally, so they could be more 'powerful' and flexible and cover more use cases, however unlikely they are to occur. With this flexibility and 'power' comes complexity and so the solution becomes less usable as it's not no longer being designed for a specific use, moment in time, type of colleague etc. instead it's more based on 'what ifs', assumptions and 'it would be good if it can do ...'. You loose track of what the user goals are, what decisions are needed to be made, what the workflows are.
So although enterprise systems aren't focussed relentless on conversation and optimisation, making sure that there are always new people being added to the funnel and making sure that any bounces, drop offs, or friction within the funnel is reduced. There are other pressures and complexity in designing enterprise experiences.
Organisations are maturing and experience design now plays a key role in large organisations and enterprises around the globe. Colleague Experience is a key to unlocking operational efficiencies, provide more flexible ways of working and also improve the overall customer experience, by improving the tools that support the customer experience behind the scenes.
Some of the key catalysts for being able to design enterprise level experiences is the rise of organisations from being less tactical to being more strategic and the key role that design and experiences plays today at large organisations and enterprises across the globe. With founders and also board level executives with either design in their title or user experience as an active interest and adopter or supporter of Design Thinking.